Let's take a closer look at each of these three converging technologies.
Embedded Linux
Linus Torvalds has been pointing in an embedded direction for a long time, starting with his own career path. In 1997, Linus moved from Finland to Silicon Valley, where he went to work for the famously secretive Transmeta. While Linus has been extremely discreet about Transmeta's work, he has been more forthcoming about his interest in appliances and embedded applications. Hardly a speech or an interview goes by without mention of embedded Linux possibilities.
In fact, Linus helped develop Transmeta's own Mobile Linux, which is ROM-based and customized for Transmeta's own TM3120 Crusoe processor. Here's what Linus said about it when I talked with him on Transmeta's launch day, earlier this year: "It's the standard 2.3 kernel with some power management stuff done on it, but anybody can see what that is. There is the compressed file system that I made part of the standard kernel not long ago. And that's really the question of ... you have a very limited amount of ROM. You want to fit Netscape in there, too. And you want to page things in from the ROM. You obviously want to compress it. That's number one. But how do you compress it so you can still do random seeks and paging in things? Those are the kinds of questions I spent a fair amont of time thinking about. What's the good way of doing this? What fits in and works well? These are not fundamental design shifts."
They aren't fundamental design shifts because Linux is already well-adapted — or adaptable — to the embedded application world.
Lately the hot embedded topic is "appliances." Mobility is another hot issue. Both suggest that the embedded world is about physically small things. But to embedded systems, size isn't the issue. Purpose is. A massive telephone switching system may have a specialty no larger in operational scope than a pager. Both are special. Neither is general.
For all of computing's history, the difference between "special" and "general" operating systems was not just a matter of scope. It was a massive difference in kind. Nearly every attempt to leverage one to the other failed. Apple, AT&T and Microsoft, all successful at creating large general purpose operating systems, failed (or were at least frustrated) in their attempts to make special ones. Novell also failed to recast NetWare — an extremely successful special purpose network operating system — as a general purpose competitor for Windows NT.
| "When you have thousands of developers working on millions of lines of code, it is absolutely critical to support both clean interfaces and the ability to rip out somebody else's code and still have your code work. A happy consequence of the open source model is that Linux evolved, by necessity, to be more modular, and to support cleaner interfaces, than a monolithic design that assumes less anarchistic control. As a result, Linux kernels as small as 300KB can not only boot up with networking support, but serve web pages as well. This is really exciting to people who want to put web servers (and adminstrative consoles) everywhere.
Another reason that makes Linux so attractive for embedded systems is the fact that you can use the same APIs for development and deployment. While this is not a new goal, the reality of a system that (1) works, (2) people actually like to program, and (3) supports tons of content, has expanded the realm of embedded system development from a highly specialized art to something any Linux programmer can manage. This dramatic expansion of the developer base is going to have a profound impact on the embedded system market. It is always difficult to say who has the "best" version of embedded linux. Our take is that even in embedded, There Is Only One Linux. Namely, we're building configuration tools (open source, of course), which make it possible to take a stock Red Hat 6.2 distribution, configure out 99.99% of stuff that's not relevant for an embedded system, and voila, it's still Red Hat. Others are taking different approaches, such as offering many different versions of Linux for many different markets, but we believe in the One Source approach. It's more maintainable, and we believe it will better server a larger number of developers over the long run. — Michael Tiemann, Chief Technology Officer, RedHat |
So for decades the embedded world has largely been the province of well-niched embedded OS companies such as Wind River and Mentor Graphics. The market was hardly small. Today Wind River <www.windriver.com> alone has sales pushing $200 million/year, and a market cap of nearly $3 billion. But for the most part it was safe from Microsoft and everybody else who made a general purpose operating system.
But now Linux is invading this world in a huge way. Suddenly old real-timers are either adopting Linux or being adopted by Linux companies. James Ready, the embedded pioneer who founded Ready Systems a few years back, now runs MontaVista <www.mvista.com>, which launched HardHat Linux last year. RedHat acquired Cygnus last Fall, then added WireSpeed in June of this year. (The sidebar is by Michael Tiemann, the Red Hat CTO who founded Cygnus.) Last summer Caldera, an early Linux distribution leader, spun off Lineo as an embedded Linux company. Both Lineo and MontaVista have substantial venture capital backing, and are themselves in aggressive acquisition modes. And now the traditional embedded publications and events are suddenly abuzz with Linux coverage.
Why Linux? Here's John Bork of Intel, which built its new Web and set-top boxes on a combination of embedded Linux and customized Mozilla : "We just take the source off the Net, pull out the stuff we don't need, seeing what libraries are used and not used, and constraining ourselves from there. See, the biggest challenge we face is getting the OS, the browser, the plug-ins and a few applets into eight megabytes of flash. So a lot of our work has gone into analysing what pieces we need, and how we skinny this thing down."
Another virtue is the vast reservoir of talent working on Linux — plus the sex appeal of embedded work on fun new projects. Kerbango is a new company working on a stand-alone radio that tunes audio streams off the Web. "I enjoy working on server farms like I did at my last job," says one Linux programmer at Kerbango, "But I love working on cool new stuff." In the past, learning a whole new operating system and all its tools was expensive in both time and money. Not so with Linux. An embedded application might be extremely arcane, but the operating system knowledge required is not. That can hold down NRE (non-recoverable engineering) costs to a highly significant degree.
So what we have with Linux is the first general purpose operating system that adapts quickly and easily to special purposes, and brings along most of its own special virtues as well.
Instant (or Live) Messaging
The biggest problem with Instant Messaging isn't that AOL wants to dominate the category. It's that most of the world only knows what AOL means by the term.
Instant messaging (IM) first showed up in early 1984 as a real-time text chat feature in bulletin board systems (BBSes). "Chat rooms" soon became standard features of AOL, Compuserve and other online services. In 1988, AOL rolled out a 'buddy list' in its own client software and later broke that off into a standalone client called AIM (AOL Instant Messenger). Other buddy/chat systems showed up in the late 90s. Excite, Yahoo and Microsoft (among many others) began to offer featured free IM clients for download, and arranged communications over the Net by way of their own proprietary systems. For a while the most successful of these was Marabilis' ICQ, which quickly became a paradigm case of success with "viral" marketing. Nearly all Mirabilis' promotion was by word of mouth. Mirabilis is now part of AOL, which is why AOL dominates conersation about the topic, if not the category.
That category includes just about all text-based live communications over the Net — between any body and any thing. That begins to put our AIM/ICQ-level of IM understanding in perspective.
Technically, IM is about two functions: presence and messaging. The first involves detecting and revealing the availability of another indentity on the network. The second involves one-to-one (or one-to-few) live text exchanges with one or more present members of a list.
In enterprises where IM is widely adopted, life isn't the same for other technologies. "It changes the sociology of telephony," says Udi Shapiro, an instant messaging pioneer whose company created Lotus' Sametime IM software. Live text exchanges can invite or replace phone calls. Groups of people can get together and come to quick agreements.
It's not hard to imagine what IM can do for communications between humans. The dark or gray area is communications between humans and remote machines, or among machines themselves.
Combination of IM and embedded
The value of the combination of embedded linux and instant messaging is that embedded Linux is the device driver in the API, and instant messaging provides the framework for registration and lookup. Through your instant messenger, the client says to the server "I'm online," and the server notifies other clients of that fact, providing the path for direct communications. Thus instant messaging becomes an ideal way to set up point-to-point communications between two uknown entities.
The best working example of this arrangement is celluar telephony. The problem with that example, however, is that cell phones are physical devices. The system doesn't know the identity of the user — only the phone number and the unique identity of the phone it is assigned to. With IM you can locate the person or the identity of the device. In either case, it's a logical connection and not just a physical one.
IM is also similar to cellular telephony in its real-time nature. If you think of embedded messaging as a service, it makes no sense to have a store & forward, because you are working mostly in real time. A special purpose device doesn't have the peripheral support that a general purpose device will. Including, say, storage. There's no point to it. So in live communications, a real time connnection can be established through IM.
Enter XML
XML was created to package and exchange structured data — files, blocks of text, drawings, transactions, settings, whatever — on its own terms, outside the context of the programs that produce them, and (most importantly) outside the API and protocol walls that keep services from interoperating over the Net. XML provides the basic rules for organizing content, but not for identifying it. So, while XML resembles HTML in its use of tags, it differs radically from HTML by not forcing a meaning for those tags on the data itself. Those agreements are up to those communicating within an XML framework.
This puts XML in the position of serving as a framework for dynamic protocols. A parser has to be present on both sides of any device dialog, or any element that participates in that infrastructual framework, but between parser and par
Let's run down what's required for XML to work.
XML is an HTML data stream. It's tags. And it's tags that the browser may or may not ever see. What happens with tags in a browser is that tghe b interprets them and displays what th e tags indicate. Now, what is it that interprets the XML datastream? An XML parser. Any time a browser isn't present, something has to parse or interpret the data stream. A browser is a relatively general purpose app, even when harnessed to a TV s4et top box. If I'm a telephone or a switch, I'm special purpose regardless of footprint size, and I don't need a browser.
T^hen you need an app at the other end of the parser that can take action with the parsed XML streams. That will be arcane to the special purpose of the device. You need a small, special purpose web server.
Wouldn;t it be cool if you havwe a web server on a device. You can query a device and control it from a browser, which a web service. This is the way, say, the cobalt qube works. Not rocket science.
What does instant messaging do? What does it do with a system as a service? It allows real time (or real time enough) registration, connection and point to point information exchange, based on a person on a device. In the embedded context, we're talking ablout a logical entity on a device. To be able to do that, base on a logical entity, is pretty neat.
Let's distinguish instant from store and forward. Once you do that a lot of other things pop out.
Look at the table. Routing tables are not physical things. We're dealing with four layers. Everything below the app layer is infrastructure. And much of that is logical. But 
that doesn;t make it dynamic. An d when you're working in real time, or close to it, between logical entities that need to establish content on an ad hoc basis, you need dynamic relationships, and they need to register themselves so something that can find them and find somethign that's been registered. Now AIM and ICQ are doing this. But they're using their own protocol, not anyone else's. and they have no interest in having anybody else play in their game, which is about holding eyeballs still for advertising, not any other kind of se4rvice.
how to deal with protocols. It is not having a dynamic protocol framework is the gating issue for innovation in services. Part of the problem is that we cant imagine past static protocols. There was no alternative. XML is the basis for a dynamic protocol framework. It's the best use of XML that I've ever seen anyone articulate. its design is suitable. We have the same problem as copercnicus. Two moving bodies have a dynamic relationship. It has the structure that has the ability to discover and establish a relationshiip between two independent entities the nature of two entities in real time, dynamically. Provided they both have a parser. You need some agreement about object models
Jabber provides an additional set of xml based services that are not avail abot in any other service set. When I look at file, print, etc. the services required by IM aren't covered. The fact that I'm usintg XML is a bonus. Because I dkln't need to estqablish a fixed protocol to get to those services. Kim cameron articulated i t best. By picking xml as the protocol framework by which a service consumer communcates witha service provider, those parties have an unparalleled level of independence. they can both work at some level and innovate simulataneously without tripping each other up.
With a fixed protocol athe consumer and the proder have to freeze themselves in time and wait for the next innovation, and then they might not match. Independence while maintaining a relationshp is the virtue here.
heavenly bodies operated and existed with each other even though we didn't have a mathematical model to describe that. devices have not had the same kind of relationship for lack of a model to implement it. With XML we have that. XML makes IM sweet becaue additional and more advanced IM services emerge. And XML provides the framework for access to those independently of each other.
what we're sayin is that IM services we have today won't remain static or single vendor.
instant messaging
how to deal with
Craig: From the technological perspective, embedded technology can be broken down into two elements:
Embedded Linux—an alternative stripped down device driver
Embedded Live Messaging—easy locater and data stream manager
With the advent of the Web, the symmetrical client/server development model of the times went out the window. In other words, the total device domination Microsoft had went away in a puff of smoke. On the one side of things, Solaris and Linux are doing very well with infrastructure. On the other side of things, embedded Linux is supposedly poised to take on small device connectivity.